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I. REAL PARTY IN INTEREST 

The real party in interest for this appeal is Microsoft Corporation. 

II. RELATED APPEALS, INTERFERENCES, AND JUDICIAL PROCEEDINGS 

Applicant, applicant's legal representative, and the real party in interest are unaware 
of any other appeal, interference, or judicial proceeding that may relate to, directly affect or 
be directly affected by, or have a bearing on the Board's decision in the present appeal. 

III. STATUS OF CLAIMS 

Claims 1-4 and 6-32 are pending in the present application and are the subject of 
this appeal. Claim 5 has been canceled. 

IV. STATUS OF AMENDMENTS 

Applicant filed an amendment on May 2, 2006, subsequent to the last Office Action 
mailed February 28, 2006. The Examiner has indicated that the amendment will be 
entered for purposes of this appeal. (Advisory Action, June 5, 2006.) 

V. SUMMARY OF CLAIMED SUBJECT MATTER 
A. Overview of the Invention and Prior Art 

1. The Invention 

Applicant's invention is directed to a technology that facilitates maintaining accurate 
presence information for a user who is logged on with two or more clients, such as in an 
instant messaging environment. (See, e.g., Specification, 8:8-12.) Instant messaging is a 
form of electronic communication that allows real time electronic communications among 
users. The ability to communicate in real time is one of the primary differences between 
instant messaging and other forms of electronic communication, such as email. (See, e.g., 
Specification, 2:12-20.) Notifying other instant messaging users of a particular user's 
status (e.g., available, away, busy) is an essential component of instant messaging. For 
example, if a first user is notified that a second user is away from his computer, the first 



41 826-8883.US00/LEGAL1 2268909. 1 



Application No.: 09/318,447 Docket No.: 418268883US 

user may decide not to compose and send an instant message to the second user 
because the second user will not receive the message in real time. (See, e.g., 
Specification, 3:5-18.) A user's status may be referred to as "presence information," and 
may be provided to other users as indicative of the user's availability. (See, e.g., 
Specification, 2:24-3:4.) 

Providing other users with accurate presence information for a particular user may 
become difficult when the user is associated with or logged on to more than one client. 
(See, e.g., Specification, 4:3-9.) For example, a user may log on to the instant messaging 
environment with an identity (e.g., user@xxx.com) using a desktop computer and again 
with the same identity using a personal digital assistant. Each client may indicate a 
different status for the user. For example, the user may be idle on the desktop computer 
but busy on the personal digital assistant. Providing accurate presence information was 
not a problem with prior techniques because the prior techniques required that a user be 
logged on to only one device at a time. Applicant's technology allows a user to be logged 
on to two or more devices at the same time. 

Applicant's technology evaluates the user's status on each of the two or more 
clients, including any status update (e.g., a change in status from away to busy), to 
determine an accurate master, or overall, status for the user. (See, e.g., Specification, 
5:24-6:5.) For example, the user who is idle on a desktop computer but busy on a 
personal digital assistant may have an overall status of busy, because even though the 
user is idle at one client, the user is busy at another. To determine the master status, 
applicant's technology first creates and maintains a client view status for each client. Each 
client view status correlates to the status of the client, e.g., online, offline, away, invisible, 
busy, etc. (See, e.g., Specification, 5:17-22.) Applicant's technology determines the 
master status of the user by evaluating each of the client view statuses and any status 
update. (See, e.g., Specification, 5:24-6:2.) In some embodiments, applicant's technology 
determines the master status according to specified priority rules. For example, if the 
status of one client changes to offline, applicant's technology will not update the master 
status to offline unless the user is offline on all other clients. This allows a user who is, for 
example, busy on one client but offline on another to still be accurately reflected as busy. 
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(See, e.g., Specification, 19:10-20:13.) Once the master status has been determined, 
applicant's technology may provide the master status to the user and to other users for use 
in determining how best to communicate with the user. (See, e.g., Specification, 6:3-5.) 

The Bunney Reference 
Bunney discloses a solution to a problem that may occur when a user is logged in 
with one of several addresses, and the other addresses assigned to the user are not in a 
logged in state. In such a situation, the user may not receive messages addressed to any 
of the user's non-logged in addresses. (Bunney, 1:24-30.) For example, a user may have 
the identities of "George@compu.xxx.com" and "Superman@sport.xxx.com." Bunney 
describes that under the prior art, if a user was logged in with the address 
"George@compu.xxx.com" and a message was sent to "Superman@sport.xxx.com," the 
user would not be notified of the message until the next time the user logged in with the 
address "Superrjnan@sport.xxx.com." 

Bunney'sj solution is to notify a user who is logged in with the first of several 
addresses of a rtnessage received at a second, non-logged in address. (Bunney, 1:45-48.) 
Under the apove example, if a user was logged in with the address 
"George@compu.xxx.com" and a message was sent to "Superman@sport.xxx.com," the 
user may be rhotified of the message through the user's "George@compu.xxx.com" 
identity. The us|er could then log out of the "George@compu.xxx.com" identity and log in 
using the identity of "Superman@sport.xxx.com" to review the message. To provide this 
notification, Bunney describes a server that maintains a table associating a user with each 
of several addresses assigned to the user. (Bunney 1 :56-59.) When a message is sent to 
one of the user'is non-logged in addresses, the server consults the table of assignments to 
identify the assigned addresses and then checks whether the user is currently logged in to 
one of those addresses. If so, the server may send a notification to the user's logged in 
address that the user has received a message at one of the user's non-logged in 
addresses. (Bupney, 1:60-67.) 

Under Bijmney, when a user is logged in, the user may have one of four statuses: 
available, invisible, away, and busy. (Bunney, 7:5-30.) A status of invisible prevents a 
user from being visible to other users' searches and from receiving other users' 
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notifications. According to Bunney, if a user is invisible, other users will not know anything 
about the user, including that the user is online. 

In addition to, but distinctive from, the statuses described above, Bunney allows a 
user who is logged in through one address to associate a do not disturb sign with one or 
more of the ussr's other addresses. For example, a user logged in with the address 
"George@compu.xxx.com" can place a do not disturb sign that indicates he does not want 
to receive any message or notification addressed to his other address 
"Superman@spDrt.xxx.com." (Bunney, 9:25-35.) Bunney's Session Manager monitors 
whether a user has placed a do not disturb sign and communicates with the Notification 
Server, which u ses the information to determine whether to send notifications to the user. 
(Bunney, 4:38-47.) 

3. The Runyan Reference 



i log 



Runyan 
one user can 
security measurfe ; 
user may log in 

4. 



cjescribes improving security on NetWare networks. Runyan describes that 
in to a network from more than one workstation at the same time. As a 
, Runyan suggests limiting the number of workstations from which one 
at the same time, using the same user identification. 

The Aravamudan Reference 



system. A us 
attributes that 
One of the 
exemplary 
group of buddiejs: 
has access to 
other. For 
whether a user 
proxy. Buddies 
anytime the use 



Aravamupan describes a messaging solution that features a user-selected priority 
r may create groups of buddies (e.g., other users) and define specific 
re associated with the buddies in each group. (Aravamudan, 2:33-35.) 
to be defined by the user is a user-selected priority system. In the 
mt described, the user may assign one of three priorities to each 
: low, high, or highest. These priorities determine whether another user 
user's presence information and how the users will interact with each 
le, buddies who are assigned a low priority will never be able to see 
is online or offline, and will always communicate with the user via a user 
who are assigned a high priority will be able to see the user's online status 
is online. Buddies who are assigned the highest priority can interface 



attributes 



tie 
- exainph 
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The rejected independent claims are directed to maintaining accurate presence 
information for s user who is logged on to two or more clients. The independent claims are 
described as fol ows: 
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when the user is online and via user proxy when the user is offline. 
35-49.) 



Claim 1 



Claim 1 i ; directed to a method at a server computer system for updating a master 
status of an electronic messaging user not withstanding that a first client computer system 
and a second client computer system may indicate different statuses for the electronic 
messaging user. The server computer system is network connectable to a plurality of 
client computer systems. At least first and second client computer systems are configured 
to indicate a status for and to send and receive electronic messages for an electronic 
messaging user identified by a user identification. (See, e.g., Specification, 8:10-12.) The 
master status is the status that is reflected to other client computer systems. The method 
maintains at the server a first view status for the electronic messaging user identified by 
the user identification, the first view status indicating the status of the electronic messaging 
user as detected at the first client computer system when the user is logged on via the first 
client computer system as an electronic messaging user. The method also maintains at 
the server a second view status for the electronic messaging user identified by the user 
identification, the second view status indicating the status of the electronic messaging user 
as detected at the second client computer system when the user is logged on via the 
second client ccmputer system as an electronic messaging user. (See, e.g., Specification, 
16:5-6.) The method receives at the server a first status update from the first client 
computer system, the first status update indicating that the first client computer system has 
detected a change in the status of the electronic messaging user identified by the user 
identification, th= change in status corresponding to the first client computer system. In 
response to receiving a status update, the server evaluates at least the first status update, 
the first view status, and the second view status according to specified status rules to 
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determine the master status of the electronic messaging user identified by the user 
identification who is logged on via both the first client computer system and the second 
client computer system as an electronic messaging user. (See, e.g., Specification, 19:8- 
20:13.) The method stores the master status at the server in a master view that 
corresponds to the electronic messaging user identified by the user identification. The 
method reflects an indication of the master status to other electronic messaging users. 
(See, e.g., Specification, 8:12-16.) 

2. Claim 10 

Claim 10 is directed to a method at a server for updating the presence information 
of an electronic messaging user that is to be reflected to subscribers. The server is 
network conneotable to a plurality of clients, each client in the plurality of clients 
maintaining a s:atus for an electronic messaging user identified by a user identification, 
each client configured to receive electronic messages addressed to the electronic 
messaging user identified by the user identification, the electronic messaging user having 
presence inforrration maintained at the server. The method creates at the server a view 
status for each of the one or more clients in the plurality of clients, each view status 
representing the status of the electronic messaging user identified by the user identification 
detected at a corresponding client, each view status being identified by a unique view 
identifier, the electronic messaging user identified by the user identification through at least 
two clients at the same time. (See, e.g., Specification, 8:10-12, 16:5-6.) The method 
consolidates at the server the presence information for the electronic messaging user 
identified by the user identification based on an evaluation each view status such that the 
consolidated presence information is representative of a current status of the electronic 
messaging user even if some view statuses differ, wherein the consolidated presence 
information is rr aintained in a master view. The method receives at the server a status 
update from one: of the one or more clients. The method updates in the master view at the 
server the consDlidated presence information for the electronic messaging user identified 
by the user identification based on an evaluation the status update and each view status. 
(See, e.g., Specification, 19:8-20:13.) 
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Claim 19 
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multiple clients, 
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representing the 
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the server a 
to the server, 
corresponding c 
receive electron 
client view statu^ 
identifier 
(See, e.g. 
on an evaluation 
received from 
status in acco 
view status, w 
to the master < 



representative 



multipU 
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Claim 27 
system for implementing 
instant messagirg 
the one or more 
electronic 
subscribers. 

comprises a computer- 
executed, cause 



messages 
(v>ee, 
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is directed to a method in an instant messaging group for reflecting the 
subscribers. The instant messaging group has a user associated with 
each client configured to detect a status of the user and to send and 
messages for the user, the user having consolidated presence 
of a master status stored at a server, the master status 
status that is reflected to subscribers even if the user status detected at 
le clients differs. For each of the multiple clients, the method creates at 
view status when each of the multiple clients sends a first status change 
client view status representing the status of the user as detected at a 
ient, the user being logged on to at least two clients at the same time to 
c messages. The method assigns at the server a view identifier to each 
when the first status change is received at the server, wherein each view 
tes one of the multiple clients with a corresponding client view status. 

, 16:5-6.) The method sets at the server the master status based 
of each client view status. For each subsequent status change that is 
of the multiple clients at the server, the method updates the master 
;e with an evaluation of the subsequent status change and each client 
n the presence information reflected to other subscribers corresponds 
, (See, e.g., Specification, 19:8-20:13.) 

Claim 27 



o le 



is directed to a computer program product for use in an instant messaging 
a method for updating the presence information of a user. The 
system has a user associated with one or more clients, each client in 
clients configured to detect a status of the user and to send and receive 
for the user, the user having presence information reflected to 
e.g., Specification, 8:10-12.) The computer program product 
readable medium carrying executable instructions that, when 
a server to create at the server a view status for each of the one or more 



two ( 



the s 
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status representing the status of the user detected at the corresponding 
status being identified by a unique view identifier, the user being logged 
clients at the same time to receive electronic messages. (See, e.g., 
:5-6.) The computer program product comprises a computer-readable 
executable instructions that, when executed, cause a server to 
server presence information for the user is based on an evaluation of 
such that the consolidated presence information is representative of the 
the user. The computer program product comprises a computer-readable 
executable instructions that, when executed, cause a server to receive at 
update from one of the one or more clients. The computer program 
a computer-readable medium carrying executable instructions that, 
cause a server to update at the server the consolidated presence 
the user according to the status update. The computer program product 
computer-readable medium carrying executable instructions that, when 
a server to reflect at the server the updated consolidated presence 
subscribers such that the appropriate presence information is provided 
even if some view statuses differ. (See, e.g., Specification, 19:8-20:13.) 

Claim 29 



) the j 



Claim 29 is directed to a method in a server for generating a master presence 
status of a user who is online via multiple clients at the same time. For each of the 
multiple clients through which the user is currently online, the method receives at the 
server receives a client presence status of the user as reported by the client. (See, e.g., 
Specification, 16::5-8, 16:13-17:14.) The method generates the master presence status 
representing a current presence status of the user based on the received client presence 
statuses reportejj by the multiple clients. (See, e.g., Specification, 19:8-20:13.) 
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VI. GROUNDS OF REJECTION TO BE REVIEWED ON APPEAL 



The 



1. 



The 



The 



under 35 U.S. 
Bunney and "Al 

2. 

as being 
and U.S. Patent 

B. Th 



Examiner's Rejections 

Examiner rejected claims 1-4, 6-8, 10-14, 16-22, 24-27 and 29-32 1 

. § 103(a) as being unpatentable over U.S. Patent No. 6,487,584 to 
quiet on the NetWare front" by Runyan. 

Examiner rejected claims 9, 15, 23, and 28-32 under 35 U.S.C. § 103(a) 
unpatentable over Bunney, Runyan, U.S. Patent No. 6,301,609 to Aravamudan, 
No. 6,480,593 to Munday. 

e Issues on Appeal 



1. 



status update 
claims. 



user may be 
when a user is 
the claims. 



3. 

electronic 
19-28. 



the 



1 The E: 
and also under 
this appeal, appjicant 
combination of 
basis for rejecting 



ther Bunney suggests determining a master status in accordance with a 
I each client view status. The decision on this issue impacts all of the 



3r one would be motivated to combine Runyan's suggestion that a 
logged on to several clients with Bunney's solution to a problem that occurs 
logged on to only one address. The decision on this issue impacts all of 



Wpether Bunney suggests reflecting the master status of the user to other 
messaging users. The decision on this issue impacts claims 1-4, 6-9, 16, and 



has rejected claims 29-32 under the combination of Bunney and Runyan 
combination of Bunney, Runyan, Aravamudan, and Munday. For purposes of 
assumes that the Examiner intended to reject these claims under the 
Sunney and Runyan even though the Examiner provides no explanation of the 
these claims under Bunney and Runyan. 
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VII. ARGUMENTS 



O bviousness Rejections 



All of the 
U.S.C. § 103(a) 

A patent 



nay not be obtained though the invention is not identically disclosed 
or described as set forth in section 102 of this title, if the differences between 
the subject matter sought to be patented and the prior art are such that the 
subject matter as a whole would have been obvious at the time the invention 
was mace to a person having ordinary skill in the art to which said subject 
matter portains. Patentability shall not be negatived by the manner in which 
the invention was made. 



"[T]he [Ejxamin^r 
In re Rijckaert, 
prima facie cash 
would appear tc 
the art.'" Id. (qioting 
Cir. 1993)). 
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the combination of Bunney, Runyan, and Aravamudan suggests 
status according to a detailed priority system. The decision on this 
9, 15, 23, and 28. 



Legal Standards for Obviousness 

claims on appeal stand rejected as obvious under 35 U.S.C. § 103(a). 35 
provides: 



bears the initial burden of presenting a prima facie case of obviousness." 
F.3d 1531, 1532, 28 U.S.P.Q.2d (BNA) 1955, 1956 (Fed. Cir. 1993). '"A 
of obviousness is established when the teachings from the prior art itself 
have suggested the claimed subject matter to a person of ordinary skill in 
In re Bell, 991 F.2d 781, 783, 26 U.S.P.Q.2d (BNA) 1529, 1531 (Fed. 



To estab ish a prima facie case of obviousness, the Examiner must (1) identify prior 
art references t lat disclose all the elements of the claims, and (2) provide a suggestion or 
motivation to rrodify the references to produce the claimed invention. (MPEP §2143.) 
With respect tc the second requirement, the Examiner must provide a suggestion or 
motivation to combine from within the prior art, and may not rely on hindsight gleaned from 
applicants' inveition itself. See, e.g., Uniroyal, Inc. v. Rudkin-Wiley Corp., 837 F.2d 1044, 
1050-51, 5 U.S.P.Q.2d 1434, 1438 (Fed. Cir. 1988). 
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the 



3se standards, applicants' invention would not have been obvious. The 
lot identified prior art references that disclose all the elements of the 
The Examiner also has not provided any motivation from within the prior 
cited references so as to produce the claimed invention. Therefore, the 
Claims should be reversed. 

Discussion of Issues 



art to applicant' 
Examiner argu< 
applicant's "maiter 
also argues tha 
users correspond; 
2006, p. 4.) It i 
corresponds to 
status correspond: 
status is dete 
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the Examiner, 
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each of the Exs 



"first 
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In rejecting the pending claims, the Examiner has mapped the elements of the prior 
claim elements in inconsistent and contradictory ways. For example, the 
; that Bunney's address with which the user is logged in corresponds to 
status." (Office Action, Feb. 28, 2006, p. 4.) However, the Examiner 
Bunney's providing a user's status (e.g., available, away, or busy) to other 
Is to applicant's "reflecting" the master status. (Office Action, Feb. 28, 
contradictory for the Examiner to take the position that Bunney's address 
applicant's master status and then to take the position that Bunney's user 
s to applicant's master status. As another example, applicant's master 
by evaluating "a first status update, a first view status, and a second 
The Examiner, however, points to Bunney's address as corresponding to 
view status." Thus, the Examiner argues that Bunney's address 
both applicant's master status and first view status. Because applicant's 
determined by evaluating the first view status in addition to other factors, 
, the Examiner's suggestion that applicant's master status is the same as 
Aew status is inconsistent. Because of the inconsistent positions taken by 
t is difficult for applicant to respond to the Examiner's arguments in as 
a manner as applicant would like. Applicant has attempted to respond to 
's contradictory arguments. 
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a. Bunnev fails to teach or suggest determining a master 
status in accordance with an evaluation of a status 
update and each client view status. 

All of the Iclaims recite determining a master status in accordance with an evaluation 
of a status upda:e and each client view status. For example, claim 1 recites: 



the first 

according 

electronic 



in response to receiving the first status update, the server evaluating at least 
status update, the first view status, and the second view status 
to specified status rules to determine the master status of the 
messaging user ... 

he server receives a status update when one of the user's client computer 
a change in the status of the electronic messaging user, e.g., a change 
(Specification, 14:1-2.) The server evaluates the status update and 
other client computer systems, which are obtained from each client view 
by the server. The server uses specified rules to reconcile differing 
determine the master status. 



In other words, 
systems detects 
from away to 
the statuses of 
status maintained 
statuses and 



busy, 
all c 



Bunney 
status." 
"evaluating at 
status," as de; 
master status, 
address to senc 
Examiner's 
which a user 
concepts are di 
status (e.g., on 
update and the 
through which 
update or client 

Further, 
applicant's "first 
described above. 



Applicant' 



pos tion 
has 



tne 
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does not describe any element that corresponds to applicant's "master 
s master status of an electronic messaging user is determined by 
l^ast the first status update, the first view status, and the second view 
above. The Examiner points to Bunney at 9:1-20 as disclosing a 
explaining that "Bunney discloses the server checking a table to see which 
a notification to." (Office Action, Feb. 28, 2006, p. 4.) It is apparently the 
that Bunney's "address to send a notification to" (i.e., the address with 
logged in) corresponds to applicant's "master status." However, these 
itinct. Applicant's master status is not an address; rather, it is an overall 
ine, offline, away, busy, invisible) that is formed by evaluating the status 
client view statuses according to specified rules. In contrast, the address 
user has logged on in Bunney is not determined by evaluating a status 
view statuses, nor is it determined according to specified status rules. 

the Examiner believes that Bunney's logged on address corresponds to 
view status," in addition to corresponding to applicant's master status, as 
When discussing applicant's claim language "maintaining at the server a 
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view status and 
by "evaluating 
status." Clearly, 
has pointed to a 
a single address 

Even if 
master status in 
status. Bunney' 
which may inch 
user's status is 
Bunney allowed 
offers no teaching 
status to determine 
example, where 

The 

Indeed, Runyan 
a master status 



the 

computer 
messaging 

For example, a 

a desktop compluter 
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1 the Examiner states that "Bunney discloses an address a user has 
a certain terminal." (Office Action, Feb. 28, 2006, p. 3.) Applicant's first 
master status are two different statuses. The master status is determined 
least the first status update, the first view status, and the second view 
applicant's first view status and master status are distinct. The Examiner 
single address as corresponding to both statuses, without explaining how 
can correspond to both statuses. 
Bjjnney disclosed a master status, Bunney does not disclose determining a 
accordance with an evaluation of a status change and each client view 
5 Session Manager does maintain information about the status of a user, 
available, away, invisible, or busy. (Bunney, 7:5-9.) Except when a 
invisible, the status is displayed to other network users. However, even if 
a user to be logged in to two or more clients at the same time, Bunney 
that it would attempt to evaluate a status change and each client view 
a master status. Bunney offers no guidance to remedy a situation, for 
a user is "busy" on one client and "available" on another. 

does not rely on Runyan for curing this deficiency of Bunney. 
cannot cure this deficiency, as it neither teaches nor suggests determining 
or a user. 

The Examiner's suggestion to modify Bunney with 
Runvan's suggestion that a user may be logged on to 
several clients would obviate the need for Bunney's 
solution, which the Examiner relies upon in rejecting the 
claims. 

All of the ;laims recite that an electronic messaging user is logged on to at least two 
clients at the sarpe time. For example, claim 1 recites: 



Examiner 



>nic messaging user ... who is logged on via both the first client 
system and the second client computer system as an electronic 
user. 

user may be logged on to an instant messaging environment through both 
and a personal digital assistant. Applicant's claims are directed to 
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maintaining a 
offline, away, bu 

The 
electronic 
Examiner points 
Runyan 

operating systei|n 
contradictory to 
user is logged i 
several workstal 
has several add 
message is sen: 
intends to solve 



mlaster status for the user even though the status of the user (e.g., online, 
sy) may differ on the desktop computer and the personal digital assistant. 

niner acknowledges that Bunney fails to teach the limitation of an 
iging user logged on to at least two clients at the same time. The 
to Runyan to cure this deficiency. (Office Action, Feb. 28, 2006, p. 4.) 
ss that a user may be logged in to a NetWare network, or a network 
from one or more different workstations. It would, however, be 
combine Bunney's technique that solves a problem that occurs when a 
i on one address with Runyan's technique that allows a user to log in at 
ons. Bunney is designed to address a problem that occurs when a user 
esses, the user is logged in to a network under only one address, and a 
to another of the user's addresses. Bunney describes the problem it 



as follows: 

when the user has logged in with one of said several addresses, and the 
other addresses assigned to the same user are not in a loqged-in state , no 



message 
forwarded 
of the 



(Bunney, 1:24- 
describes a user 
or another user 
user's addresse 
assignment 
is logged in to 
through the 
non-logged in 
Manager "allows 
added.) 

It is the 
Runyan to have 
time "because it 
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or notification from a server or another user terminal can be 
to the user, when the notification or message is addressed to one 
adcresses which are in a non-logged-in state. 

3p, emphasis added.) In explaining its solution to this problem, Bunney 

logged in to a network with one of the user's several addresses. A server 

sends a message to a second of the user's addresses, i.e., one of the 

5 that is in a non-logged in state. The server consults its table of 

information to determine whether the user associated with the second address 

tlje network through another address. If so, the server will notify the user 

logged in address that a message has been sent to the user's second, 

Iress. (Bunney, 1:60-67.) Further, Bunney emphasizes that its Session 

a user to log into the system once ..." (Bunney, 4:35-36, emphasis 



Examiner's position that one would be motivated to combine Bunney and 
m electronic messaging user logged on to at least two clients at the same 
allows the user to be logged onto multiple devices and it allows other 
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i them 



addresses woulq 
were logged on 
to any of the us 
need for BunneV 
received at one 
suggestion is 
avoid the probl 
multiple addi 



based on their state." (Office Action, Feb. 28, 2006, p. 4.) Combining 
to allow a user to be logged on to multiple devices using different 
however, entirely avoid the problem Bunney attempts to solve. If a user 
to a device for each of his different addresses, and a message were sent 
's addresses, the user would receive the message. There would be no 
's solution, i.e., providing notification to the user that a message has been 
of the user's addresses that is not in a logged on state. The Examiner's 
not a suggestion to modify Bunney, but rather a suggestion to entirely 
;m Bunney attempts to solve by requiring the user to log on through 



thus 



Runyan's multipjli 
Bunney's 
(Office Action, 
however, if 
suggested by 
contradictory 



Many of 
messaging usei 
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Furthermore, the Examiner's rejection relies upon both Bunney's solution and 
le log on in rejecting the claims. For example, the Examiner relies upon 
solution of "checking the table to see which address to send a notification to." 
eb. 28, 2006, p. 4.) Such checking of a table would not be needed, 
Buihney was modified to allow a user to log on to multiple addresses as 
Runyan. Thus, the Examiner is applying the suggested combination in 



w£ ys. 



c. Bunney fails to teach or suggest reflecting the master 
status of the user to other electronic messaging users. 

he claims recite reflecting the master status of the user to other electronic 
. For example, claim 1 recites: 



reflecting an indication of the master status for the electronic messaging user 
identified by the user identification to other electronic messaging users. 

One of the benefits of an electronic messaging environment is that a user's status is 

reflected, e.g., c isplayed, to other users. When the user is logged on through two or more 

clients, applicait's technology reflects a user's master status to other users in the 

environment, rather than reflecting the status information of the client or clients separately. 

Even if Bunney were to create a master status, it does not disclose reflecting such a 
status to other users. The portions of Bunney cited by the Examiner do not teach or 
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reflecting the master status of the user to other electronic messaging users. 
9:25-35.) The first cited portion of Bunney describes that the Session 
is information about the user's status, which may be available, away, 
(Bunney, 7:5-30.) This status information is provided to other users, 
information maintained by Bunney's Session Manager and reflected to other 
he status of one of the user's clients; it is not a master status, determined 
3 status of each of the user's two or more clients. 



ispDrt. 



othor 
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the Examiner previously indicated that applicant's master status was 
Bunney's logged in address, as described above. It is inconsistent for the 
indicate that the master status reflected to other users is in the form of 
i (e.g., available, away, or busy). Further, even if applicant's master 
equivalent to Bunney's logged in address, Bunney's logged in address is never 
oth|er users. Accordingly, Bunney fails to teach or suggest reflecting the 
>s of the user, which the Examiner believes corresponds to applicant's 
t<f) other electronic messaging users. 

seccjnd portion of Bunney cited by the Examiner describes a "do not disturb 
De used by the user. (Bunney, 9:25-35.) A user logged in through one 
ssociate a do not disturb sign with one or more of the user's other 
example, a user logged in with the address "George@compu.xxx.com" 
not disturb sign that indicates that the user does not want to receive any 
notification addressed to the user's other address 
:.xxx.com." A do not disturb sign is not status information (e.g., 
or busy); instead, it is a separate signal used to communicate with the 
ence of a do not disturb sign is monitored by the Session Manager and is 
i the Notification Server, which uses the information to determine whether 
tions to the user. (Bunney, 4:38-47.) The do not disturb sign is not 
users; other users only have access to the status of the user, such as 
or busy. Further, the do not disturb sign is not equivalent to applicant's 
Even if Bunney were to permit an electronic messaging user to be logged 
clients at the same time, Bunney offers no teaching about how a do not 
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Dne of the user's clients (i.e., non-status information) would be reconciled 
presented by another of the user's clients. Indeed, it would be 
Attempt to reconcile these two diverse concepts. 

niner does not rely on Runyan for curing this deficiency of Bunney. 
cannot cure this deficiency, as it neither teaches nor suggests reflecting a 
a user to other electronic messaging users. 
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d. Bunney, Runyan, and Aravamudan fail to teach or 
suggest updating the master status according to a 
detailed priority system. 

)f the claims recite updating the master status according to a detailed 
For example, claim 15 recites: 



changing the presence information according to a priority system further 
)mprise3 at least one of: 

changing the presence information to offline if the status update 
indicates the electronic messaging user is invisible; 



changing the presence information to offline if the status update 
indicates the electronic messaging user is offline and the remaining 
vie w statuses indicate the electronic messaging user is offline; 

changing the presence information to idle if the status update 
[indicates] the electronic messaging user is idle and the remaining 
view statuses indicate the electronic messaging user is idle or offline; 
and 



changing the presence information to match the status update, 
r jles for changing the master status is a specific example of updating the 
evaluating "a first status update, a first view status, and a second view 
mple, the first rule applies where the first status update, and thus the first 
invisible; the second view status may be any status. When the first status 
it indicates that the user does not want to be seen by other users, 
to the first rule, the master status will be changed to offline. 

Examiner's position that Bunney discloses the first of these priority rules, 
joints to Bunney at 7:10-15 as disclosing this priority rule, explaining that 
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"Bunney discloses the use of being invisible to others." (Office Action, Feb. 28, 2006, p. 
13.) While the cited portion of Bunney does describe that a user may have a status of 
invisible, Bunne/ does not disclose changing the master status to offline if the first status 
update indicates the user is invisible. Bunney does not create or maintain a master status, 
nor does it rece ve a status update. Bunney's invisible status merely prevents a user from 
being visible to other users' searches and from receiving other users' notifications. 
According to Bunney, if a user is invisible, other users will not know anything about the 
user, not even t iat the user is online. The first priority rule is not disclosed by Bunney. 

It is the Examiner's position that Aravamudan discloses the fourth and fifth of these 
priority rules. The Examiner points to Aravamudan's abstract as teaching "the use of 
instant messaging in conjunction with access to data and communication network 
channels and rr odes" and to Aravamudan at 4:45-67 and 10:1-51 as teaching "the use of 
the proxy always appearing to the buddy and real presence being advertised to other[s] 
who have iden ified the user as a buddy." (Office Action, Feb. 28, 2006, p. 14.) The 
Examiner believes that one would be motivated to modify Bunney and Runyan in view of 
Aravamudan "because it would result in the most accurate presence for a user." (Office 
Action, Feb. 2E, 2006, p. 15.) However, rather than a priority system executed by the 
server as in applicant's technology, Aravamudan describes a priority system that is 
selected by the user. The user may assign a priority to each buddy or group of buddies. 
In the exemplary embodiment described, the user may select among low, high, and 
highest priorities. These priorities determine to what status information other users have 
access and how other users may communicate with the user. Also unlike applicant's 
technology, Aravamudan's priority system does not reconcile differing user statuses 
associated with two or more clients. Instead, priorities are assigned to other users by the 
user, and such priorities do not relate to the other user's status (e.g., available, away, 
busy). Instead the priorities determine how another user may interact with the user who 
assigned the priority. Unlike applicant's technology, Aravamudan does not teach or 
suggest a priority system executed by a server and, in particular, does not teach or 
suggest the particular priority rules as claimed. 
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Claims 1-14, 6-8, 10-14, 16-22, and 24-27, and 29-32 were rejected under 35 U.S.C. 
§ 103(a) over B jnney and Runyan. For the reasons described below, the Examiner has 
failed to establish that these claims are obvious over Bunney and Runyan. Therefore, the 
section 103(a) rejection of these claims should be reversed. 
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Response to the Section 103(a) Rejection of Claims 1-4. 6-8, 10-14, 
16-22, 24-27 and 29-32 Over Bunney and Runyan 



a. Claims 1-4 and 6-8 

and 6-8 recite "the electronic messaging user ... who is logged on via 
ient computer system and the second client computer system as an 
user." As discussed above in section 2.b, one would not be 
Runyan's suggestion that a user may be logged on to several clients 
system that allows a user to be logged on to only one address. Therefore, 
) rejection of these claims should be reversed. 

ms also recite "in response to receiving the first status update, the server 
>t the first status update, the first view status, and the second view status 
specified status rules to determine the master status of the electronic 
As discussed above in section 2. a, neither Bunney nor Runyan 
this feature. Therefore, the section 103(a) rejection of these claims 



These claims also recite "reflecting an indication of the master status for the 
electronic mess? ging user ... to other electronic messaging users." As discussed above in 
section 2.c, neither Bunney nor Runyan teaches or suggests this feature. Therefore, the 
section 103(a) rejection of these claims should be reversed. 

b. Claims 10-14 and 17-18 

Claims 10-14 and 17-18 recite "the electronic messaging user being logged on as 
an electronic messaging user ... through at least two clients at the same time." As 
discussed abov; in section 2.b, one would not be motivated to combine Runyan's 
suggestion that a user may be logged on to several clients with Bunney's system that 
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allows a user to 
of these claims j 



be logged on to only one address. Therefore, the section 103(a) rejection 
hould be reversed. 



These claims also recite: 

consolida ing at the server the presence information for the electronic messaging 
user ... based on an evaluation of each view status such that the consolidated 
presence information is representative of a current status of the electronic 
messaging user even if some view statuses differ, wherein the consolidated 
presence information is maintained in a master view; 



receiving 

updating 
the electr 
each viev\ 



at the server a status update from one of the one or more clients; and 

n the master view at the server the consolidated presence information for 
ic messaging user ... based on an evaluation of the status update and 



£-22 
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As discussed above in section 2. a, neither Bunney nor Runyan teaches or suggests this 
feature. Therefore, the section 103(a) rejection of these claims should be reversed. 

c. Claim 16 

Claim 16 hecites the language of its base claim 10 and further recites "reflecting the 
updated presence information in the master view to the subscribers." As discussed above 
in section 2.c, n« ither Bunney nor Runyan teaches or suggests this feature. Therefore, the 
section 103(a) rejection of these claims should be reversed. 

d. Claims 19-22 and 24-26 



and 24-26 recite "the user being logged onto at least two clients at the 
=ive electronic messages." As discussed above in section 2.b, one would 
to combine Runyan's suggestion that a user may be logged on to several 
r 's system that allows a user to be logged on to only one address, 
iction 103(a) rejection of these claims should be reversed. 

ms also recite: 



the server the master status based on an evaluation of each client view 



and 

for each « ubsequent status change received from one of the multiple clients at the 
server, ujdating the master status in accordance with an evaluation of the 
subsequent status change and each client view status. 
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As discussed above in section 2. a, neither Bunney nor Runyan teaches or suggests this 
feature. Therefo|re, the section 103(a) rejection of these claims should be reversed. 

These claims also recite "the presence information reflected to the subscribers 
corresponds to tie master status." As discussed above in section 2.c, neither Bunney nor 
Runyan teaches or suggests this feature. Therefore, the section 103(a) rejection of these 
claims should be reversed. 



Claim 27 
receive electronic 
motivated to con 
with Bunney's s\ 
the section 103(; 

This claim 



This clairjn 
information to 
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neither Bunney 
103(a) rejection 



e. Claim 27 

ecites "the user being logged onto at least two clients at the same time to 
messages." As discussed above in section 2.b, one would not be 
bine Runyan's suggestion that a user may be logged on to several clients 
stem that allows a user to be logged on to only one address. Therefore, 
) rejection of these claims should be reversed. 



also recites: 



consolidate at the server presence information for the user based on an evaluation 
of each view status such that the consolidated presence information is 
representative of a current status of the user; 

receive a- the server a status update from one of the one or more clients; 
update at the server the consolidated presence information for the user according to 
the status update. 

As discussed above in section 2. a, neither Bunney nor Runyan teaches or suggests this 
feature. Therefore, the section 103(a) rejection of these claims should be reversed. 



also recites "reflect at the server the updated consolidated presence 
subscribers such that the appropriate presence information is provided 
even if some view statuses differ." As discussed above in section 2.c, 
nor Runyan teaches or suggests this feature. Therefore, the section 
of these claims should be reversed. 
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Claims 
discussed abov 
suggestion that 
allows a user to 
of these claims 



32 recite "a user who is online via multiple clients at the same time." As 
e in section 2.b, one would not be motivated to combine Runyan's 
a user may be logged on to several clients with Bunney's system that 
be logged on to only one address. Therefore, the section 103(a) rejection 
should be reversed. 



Claims 9 
Runyan, 
failed to establish 
Therefore, the s 



the 



the 



These claims also recite "generating the master presence status representing a 
current presence status of the user based on the received client presence statuses 
reported by the multiple clients." As discussed above in section 2. a, neither Bunney nor 
Runyan teaches or suggests this feature. Therefore, the section 103(a) rejection of these 
claims should b$ reversed. 

Response to the Section 103(a) Rejection of Claims 9. 15. 23, and 28 
Over Bunney, Runyan, Aravamudan, and Munday 

15, 23, and 28 were rejected under 35 U.S.C. § 103(a) over Bunney, 
Aravamudan, and Munday. For the reasons described below, the Examiner has 
that these claims are obvious over Bunney, Runyan, and Aravamudan. 
iCtion 103(a) rejection of these claims should be reversed. 



a. Claims 9 

Claims 9 recites the language of its base claim 1 and further recites updating the 
master status according to a detailed priority system. Claim 9 recites: 

changing the master status according to a priority system further 



changing the master status to offline if the first status update indicates 
electronic messaging user ... is invisible; 

raining from changing the master status if the first status update 
licates electronic messaging user ... is offline; 

raining from changing the master status if the first status update 
indicates the electronic messaging user ... is idle; 

changing the master status to offline if the first status update indicates 
electronic messaging user ... is offline and one or more remaining 
v statuses associated with the messaging client, including the 
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offl 



or 

As discussed ab 
suggest this feature, 
reversed. 



changing the master status to idle if the first status update indicates 
the electronic messaging user ... is idle and one or more remaining 
vie/v statuses associated with the messaging client, including the 
view status, indicate the electronic messaging user ... is idle 
< )ffline. 



Dve in section 2.d, Bunney, Runyan, and Aravamudan each fail to teach or 
Therefore, the section 103(a) rejection of these claims should be 



Claim 15 
master status ac 



recites the language of its base claim 14 and further recites updating the 
rding to a detailed priority system. Claim 15 recites: 



chang ng the presence information according to a priority system further 
at least one of: 



comprise;, 
ch; 



As discussed 
suggest this 
reversed. 
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ianging the presence information to offline if the status update 
;ates the electronic messaging user is invisible; 

lining from changing the presence information if the status update 
ates the electronic messaging user is offline; 

ning from changing the presence information if the status update 
the electronic messaging user is idle; 

chinging the presence information to offline if the status update 
ind cates the electronic messaging user is offline and the remaining 
statuses indicate the electronic messaging user is offline; 

chinging the presence information to idle if the status update 
[indicates] the electronic messaging user is idle and the remaining 
statuses indicate the electronic messaging user is idle or offline; 
and 

changing the presence information to match the status update. 
abDve in section 2.d, Bunney, Runyan, and Aravamudan each fail to teach or 
feature. Therefore, the section 103(a) rejection of these claims should be 
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Claim 23 

Claim 23 Recites the language of its base claim 19 and further recites updating the 
master status according to a detailed priority system. Claim 23 recites: 

chang ng the master status according to a priority system further 
comprises at least one of: 

changing the master status to offline if the subsequent status update 
ind cates the user is invisible; 

refiaining from changing the master status if the status update 
ind cates the user is offline; 

regaining from changing the master status if the subsequent status 
update indicates the user is idle; 

changing the master status to offline if the subsequent status update 
9S the user is offline and the remaining client view statuses 
ind cate the user is offline; 

changing the master status to idle if the subsequent status update 
ind cates the user is idle and the remaining client view statuses 
ind cate the user is idle or offline; and 

changing the master status to match the subsequent status update. 

in section 2.d, Bunney, Runyan, and Aravamudan each fail to teach or 
i. Therefore, the section 103(a) rejection of these claims should be 



Claim 28 recites the language of its base claim 27 and further recites updating the 
master status according to a detailed priority system. Claim 28 recites: 

. updating the presence information further comprises: 

ch jnging the presence information to offline if the status update 
tes the user is invisible; 

ling from changing the presence information if the status update 
icates the user is offline; 

refraining from changing the presence information if the status update 
c icates the user is idle; 
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changing the presence information to offline if the status update 
c icates the user is offline and the remaining view statuses indicate 
the status of the user is offline; 

ch inging the presence information to idle if the status update indicates 
the; user is idle and the remaining view statuses indicate the user is 
idl 5 or offline; and 



ch 

As discussed 
suggest this fe; 
reversed. 



anging the presence information to match the status update, 
aqove in section 2.d, Bunney, Runyan, and Aravamudan each fail to teach or 
ture. Therefore, the section 103(a) rejection of these claims should be 



VIII. CONCLLSION 



Dated 



The Examiner's section 103(a) rejection should be reversed primarily because the 
relied-upon art does not establish that the following claimed features are obvious: (1) an 
electronic mess aging user logged on to at least two clients at the same time, (2) 
determining a rr aster status in accordance with an evaluation of a status update and each 
client view statu >, (3) reflecting the master status of the user to other electronic messaging 
users, and (4) u Ddating the master status according to a detailed priority system. 



Respectfully submitted, 



Maarice J. Pirio 
Registration No.: 33,273 

PERKINS COIE llp 

P.O. Box 1247 

Seattle, Washington 981 1 1-1247 
(206) 359-8000 
(206) 359-7198 (Fax) 
Attorneys for Applicants 
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APPENDIX A 



CLAIMS 



; messages 



connectable to 
computer systeijis 
electronic 
method for updaji 
the first client co 
statuses for the 
reflected to other 
maintainirg 



receiving 
firs 



the 



1. (Previously Presented) At a server computer system that is network 
plurality of client computer systems, at least first and second client 
being configured to indicate a status for and to send and receive 
for an electronic messaging user identified by a user identification, a 
ng a master status of the electronic messaging user not withstanding that 
nputer system and second client computer system may indicate different 
electronic messaging user, the master status being the status that is 
client computer systems, the method comprising: 
at the server a first view status for the electronic messaging user 
identified by the user identification, the first view status indicating the status 
of [he electronic messaging user as detected at the first client computer 
system when the user is logged on via the first client computer system as an 
electronic messaging user; 
maintainir g at the server a second view status for the electronic messaging user 
identified by the user identification, the second view status indicating the 
status of the electronic messaging user as detected at the second client 
corhputer system when the user is logged on via the second client computer 
system as an electronic messaging user; 

at the server a first status update from the first client computer system, the 
status update indicating that the first client computer system has 
?cted a change in the status of the electronic messaging user identified by 
user identification, the change in status corresponding to the first client 
computer system; 

e to receiving the first status update, the server evaluating at least the 
first status update, the first view status, and the second view status according 
to specified status rules to determine the master status of the electronic 
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me ;saging user identified by the user identification who is logged on via both 
the first client computer system and the second client computer system as an 
electronic messaging user; 
storing th 5 master status at the server in a master view corresponding to the 

ele Tronic messaging user identified by the user identification; and 
reflecting an indication of the master status for the electronic messaging user 
ide itified by the user identification to other electronic messaging users. 

2. (Previously Presented) A method as defined in claim 1 , further comprising: 
associating a first view identifier with the first view status; and 
associating a second view identifier with the second view status. 

3. (Previously Presented) A method as defined in claim 1 , further comprising: 
updating fie first view status in accordance with the first status update. 



4. (Pi 
further comprises 
update. 



r^viously Presented) A method as defined in claim 1 , wherein evaluating 
determining whether the master status should reflect the first status 



(Canceled) 

(Previously Presented) A method as defined in claim 1 , wherein the storing 
further comprises changing the master status to the status indicated in the first status 
update. 

(Previously Presented) A method as defined in claim 1, wherein the storing 
further comprises retaining the master status even though the status indicated in the first 
status update differs from the master status. 
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8. (Pr 
evaluating furthe 



)9/31 8,447 



jviously Presented) A method as defined in claim 1, wherein the 
comprises changing the master status according to a priority system. 



refraining 
ele|c 

refraining 
ele 

changing 



changing 
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(Previously Presented) A method as defined in claim 8, wherein changing 
the master status according to a priority system further comprises: 

changing he master status to offline if the first status update indicates the electronic 
messaging user identified by the user identification is invisible; 

from changing the master status if the first status update indicates 
Dtronic messaging user identified by the user identification is offline; 
from changing the master status if the first status update indicates the 
Tronic messaging user identified by the user identification is idle; 
the master status to offline if the first status update indicates the electronic 
messaging user identified by the user identification is offline and one or more 
renaining view statuses associated with the messaging client, including the 
second view status, indicate the electronic messaging user identified by the 
identification is offline; and 
the master status to idle if the first status update indicates the electronic 
messaging user identified by the user identification is idle and one or more 
renaining view statuses associated with the messaging client, including the 
second view status, indicate the electronic messaging user identified by the 
usor identification is idle or offline. 
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10. (Previously Presented) At a server that is network connectable to a plurality 
of clients, each client in the plurality of clients maintaining a status for an electronic 
messaging user identified by a user identification, each client configured to receive 
electronic messE ges addressed to the electronic messaging user identified by the user 
identification, the electronic messaging user having presence information maintained at the 
server, a method for updating the presence information that is to be reflected to 
subscribers, the nethod comprising the steps of: 

creating i t the server a view status for each of the one or more clients in the 
plu ality of clients, each view status representing the status of the electronic 
messaging user identified by the user identification detected at a 
cor esponding client, each view status being identified by a unique view 
identifier, the electronic messaging user being logged on as an electronic 
ging user identified by the user identification through at least two 
at the same time; 

ing at the server the presence information for the electronic messaging 
r identified by the user identification based on an evaluation of each view 
:us such that the consolidated presence information is representative of a 
rent status of the electronic messaging user even if some view statuses 
sr, wherein the consolidated presence information is maintained in a 
ster view; 

receiving bit the server a status update from one of the one or more clients; and 
updating n the master view at the server the consolidated presence information for 
the electronic messaging user identified by the user identification based on 
an evaluation of the status update and each view status. 

11. (Previously Presented) A method as defined in claim 10, wherein creating 
further comprise 5 receiving a first status change at the server, the first status change being 
representative o : an initial status of one of the one or more clients. 
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consolidating the 
determine a < 
information. 



r^viously Presented) A method as defined in claim 10, wherein 
presence information further comprises comparing each view status to 
mt status of the user, the current status corresponding to the presence 



13. (Orginal) A method as defined in claim 10, wherein each status update is 
reflected in an associated client view status, the associated client view status being 
identified by a viow identifier sent with each status update. 

14. (Previously Presented) A method as defined in claim 10, wherein updating 
further comprises changing the presence information according to a priority system. 



15. (Pr 
the presence inf 
changing 
ele 

refraining 
ele 

refraining 
ele 

changing 
ele 
the 

changing 



changing 
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sviously Presented) A method as defined in claim 14, wherein changing 

n according to a priority system further comprises at least one of: 
the presence information to offline if the status update indicates the 
:tronic messaging user is invisible; 

from changing the presence information if the status update indicates the 
:tronic messaging user is offline; 

from changing the presence information if the status update indicates the 
:tronic messaging user is idle; 

the presence information to offline if the status update indicates the 
Dtronic messaging user is offline and the remaining view statuses indicate 
electronic messaging user is offline; 

the presence information to idle if the status update the electronic 
5saging user is idle and the remaining view statuses indicate the 
Tronic messaging user is idle or offline; and 
the presence information to match the status update. 



Application No.: 
16. (Pr 
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further comprise|s 
subscribers. 



Bviously Presented) A method as defined in claim 10, wherein updating 
reflecting the updated presence information in the master view to the 



(Previously Presented) A method as defined in claim 10, wherein updating 
further comprise > changing the client view status associated with the status change, such 
that the client vie|w status accurately reflects the status change. 

(Previously Presented) A computer-readable medium having computer 
executable instructions for performing the method recited in claim 10. 



19. (Pi 
associated with 
send and receive 
information 
representing the 
some of the 
subscribers, the 

for each o 



r ;vic 



assigning 



setting at 
st 

for each 
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rr ulti 



iously Presented) In an instant messaging group having a user 
rjiultiple clients, each client configured to detect a status of the user and to 
electronic messages for the user, the user having consolidated presence 
representative of a master status stored at a server, the master status 
status that is reflected to subscribers even if the user status detected at 
iltiple clients differs, a method for reflecting the master status to 
method comprising the steps of: 
the multiple clients, creating at the server a client view status at a server 
whin each of the multiple clients sends a first status change to the server, 
h client view status representing the status of the user as detected at a 
cor esponding client, the user being logged onto at least two clients at the 
time to receive electronic messages; 
at the server a view identifier to each client view status when the first 
change is received at the server, wherein each view identifier 
one of the multiple clients with a corresponding client view status; 
he server the master status based on an evaluation of each client view 
stalls; and 

s jbsequent status change received from one of the multiple clients at the 
server, updating the master status in accordance with an evaluation of the 



ass Dciates c 
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subsequent status change and each client view status, wherein the presence 
information reflected to the subscribers corresponds to the master status. 



20. (O iginal) 
representative o 



21. (Previously Presented) A method as defined in claim 19, wherein setting the 
master status fufther comprises reflecting the master status to the subscribers. 



22. (Pieviously 
the master statjis 
system. 



offl 

changing 

USi 

offl 

changing 
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A method as defined in claim 19, wherein the client view status is 
a current status of an associated client. 



Presented) A method as defined in claim 19, wherein updating 
further comprises changing the master status according to a priority 



23. (Previously Presented) A method as defined in claim 22, wherein changing 
the master status according to a priority system further comprises at least one of: 

changing the master status to offline if the subsequent status update indicates the 
is invisible; 

refraining from changing the master status if the status update indicates the user is 
offline; 

refraining from changing the master status if the subsequent status update indicates 
the user is idle; 

changing the master status to offline if the subsequent status update indicates the 
is offline and the remaining client view statuses indicate the user is 



the master status to idle if the subsequent status update indicates the 
is idle and the remaining client view statuses indicate the user is idle or 
ne; and 

he master status to match the subsequent status update. 
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reflected to the 
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iginal) A method as defined in claim 19, wherein the master status 
subscribers is representative of a current status of the user. 
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25. (Previously Presented) A method as defined in claim 19, further comprising 
selecting one of he client view statutes to be represented in the master status. 

26. (Prsviously Presented) A computer-readable medium having computer- 
executable instructions for performing the method recited in claim 19. 

27. (Previously Presented) A computer program product for use in an instant 
messaging syst< m having a user associated with one or more clients, each client in the 
one or more cli< ;nts configured to detect a status of the user and to send and receive 
electronic messages for the user, the user having presence information reflected to 
subscribers, the computer program product for implementing a method for updating the 
presence information, the computer program product comprising: 

a computer-readable medium carrying executable instructions that, when executed, 
cause a server to perform the following: 

cremate at the server a view status for each of the one or more clients, each 
view status representing the status of the user detected at a 
corresponding client, each view status being identified by a unique 
view identifier, the user being logged onto at least two clients at the 
same time to receive electronic messages; 
consolidate at the server presence information for the user based on an 
evaluation of each view status such that the consolidated presence 
information is representative of a current status of the user; 
redeive at the server a status update from one of the one or more clients; 
update at the server the consolidated presence information for the user 
according to the status update; and 
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reflect at the server the updated consolidated presence information to the 
subscribers such that appropriate presence information is provided to 
the subscribers even if some view statuses differ. 



28. 

wherein updating 
changing 
is 

refraining 
us< 

refraining 

USi 

changing 



(Previously Presented) A computer program product as defined in claim 27, 
the presence information further comprises: 

the presence information to offline if the status update indicates the user 
invisible; 

from changing the presence information if the status update indicates the 
is offline; 

from changing the presence information if the status update indicates the 
is idle; 

the presence information to offline if the status update indicates the user 
offline and the remaining view statuses indicate the status of the user is 



29. 

presence status 

comprising: 

for each 
at 
an 
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changing the presence information to idle if the status update indicates the user is 

idlo and the remaining view statuses indicate the user is idle or offline; and 
changing the presence information to match the status update. 



(Previously Presented) A method in a server for generating a master 
of a user who is online via multiple clients at the same time, the method 



of the multiple clients through which the user is currently online, receiving 
the server a client presence status of the user as reported by the client; 



generating the master presence status representing a current presence status of 
the user based on the received client presence statuses reported by the 
mi Itiple clients. 
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30. 

presence status 
indicates that the; 
busy. 



(Previously Presented) The method of claim 29 wherein when the client 
eported by one client indicates that the user is busy and by another client 
user idle, setting the master presence status to indicate that the user is 



31. (Pr 
presence status 
master presence 
currently online. 



Bviously Presented) The method of claim 29 wherein when the client 
reported by all but one client indicates that the client is offline, setting the 
status to the client presence status of the client through which the user is 



32. (Previously Presented) The method of claim 29 including upon receiving at 
the server an inc ication that the client presence status of a client has changed, setting the 
master presence status based on the changed client presence status. 
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APPENDIX B 



Applicant 



EVIDENCE 
s not relying on any evidence. 
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APPENDIX C 



Applicant 



RELATED PROCEEDINGS 
s unaware of any related proceedings. 
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